I've been tasked with writing some DXL and it's been a while, so I thought I would check here first to see if anyone knows if this is already available somewhere...or even a portion of it, before I just start writing it.
It needs to:
1. Recursively search through a database for a character-based string; including all
items (folders, projects, etc)
modules (formal, link, & descriptive)
attributes (attribute type definitions; whether text-based, enumerated, etc; whether module-level or object level; including those driven by DXL, as well as the DXL that drives them)
views (column headers, including those driven by DXL, as well as the DXL that drives them
objects (attribute values; whether text-based, enumerated, etc; whether module-level or object level; including those driven by DXL, as well as the DXL that drives them)
2. If the search results in finding the character-based string, attempt replacement of the old string with a new string
3. Log all results of items searched and whether the character-based string is found within the item searched. If an item, module, attribute, object, view, etc is NOT searchable (i.e. due to being an OLE or due to the fact that the access rights are too restrictive to allow the executing user to search the "thing"), this unsearchable "thing" needs to be logged as such.
lnorton - Thu Feb 04 13:04:20 EST 2010 |
Re: Has anyone seen a DXL "database parser" or an exhaustive Find and Repla
kbmurphy - Thu Feb 04 13:40:00 EST 2010
My goodness. Good luck with that.
You would think it would be straightforward, but there are so many scenarios to consider. You could go through your database one piece at a time...like the first time through, just do find and replaces on text. The next time through, focus on enumerated lists. The next time through, list all OLE objects.
You could try to do an all at once approach, but since you'll have to iteratively code this anyway, I don't see a need to write just one massive DXL script.
If you're on DOORS 9, you'll have to realize that Discussions can't be edited, and are you also going to want to do view names? And you can't edit a baseline, obviously. So there's no way to 100% eliminate that term from your database.
Let us know how it goes.
|
Re: Has anyone seen a DXL "database parser" or an exhaustive Find and Replace?
llandale - Thu Feb 04 16:20:29 EST 2010
I disagree with Murphy, if you want to split up the chore then run it individually on each project. That way you only open each module once.
There are significant problems, including the fact that you are likely searching for a raw string such as "This is Secret" found in rich text, such as "This is Secret", which really looks like this:
This is *Secret*
Thus, you find plain text but replace rich text. Need a special function to do that.
You also have the very significant problem when, which I found out to my horror years ago, the replace-To text is a super-set of the replace-From text. Yup, I was asked to replace all references of the company name in the shall-statements from "ITT" to "ITTL". Got scolded harshly when the managers found several "ITTLLLL shall ..." statements after I ran the DXL a few times; I hate it when that happens. Had to write a clever Is-Sub-set/Super-set comparison function, now burried away on some CD.
If you modify an enumerated value, you need to plow through all the objects and update their value, so the old value no longer appears:
for obj in entire mod do
{ obj.NameUpdatedEnumAttr = obj.NameUpdatedEnumAttr
}
Good luck getting rid of the offending phrase in Baselines or History or OLE or Discussions or in baseline descriptions or suffixes
Not sure what to do if the phrase is inside Attr/Layout/Trigger code. Not sure what to do if you change the name of an attribute, which is referenced in ANY dxl code. Not sure what to do when you think and code and think and code and test and code and retest and code and then deploy, and then discover there are 3 more cases you didn't think of, such as checking the Descriptions of each enumerated value or column titles. Oh yes, lets nor forget about user and group names. Or how to handle LinkSetPairings for renamed link modules; or corrupted LinkSetPairings. Or deleted modules and objects. Or within all those project and module archives scattered about your network. Or in the login history. Or in all the configuration files. Or the files associated with purged modules and users still sitting on the server. Or the DXL sitting on folks local PCs. OK, that's 9 things we didn't think of at the start.
Or residual files from when a shared module was put back together on the server. Or in the Layout DXL that assembles and displays the offending phrase without actually coding it. Or invisible links.
I want my Mommy.
Or in the names and information about Partitions. Or link-set attributes. Or baseline set definitions. Or page-setups. Display-scheme names. Default email text. Or signature info. Font names. Default export folder names. Adding/ProjectAddin/et tal names. Names of pre-DOORS v5 'Pictures' still hanging around. The offending name of the database now encoded into URLs everywhere. Names folks put on lock requests, still residual somewhere. DXL Defined user attribute names. Welcome screen text. Names of Triggers. 'Locale' translations of the offending phrase. Private user dictionaries. Private display scheme names.
You can get away with not checking folk's Passwords. Phew.
What's drawn on canvases. RIF stuff perhaps?
This is not a routine chore; 'some' DXL isn't going to cut it. Good luck. You probably want to hire some DXL consultant, and I know of one willing to 'volunteer'...
If this is a 'secret' problem, then indeed you have a big problem. It would be easier to get the Secret Police to acknowlege that its now 'in the public domain' and down-classify it.
|